When sending data over a communications network, compression is a technique that is used to minimize the bandwidth required by that data in order to make the communications network more efficient. This is particularly important for communications networks that rely on wireless transmission of data. Wireless Area Network (WAN) acceleration/optimization of sending data relies on many different optimization techniques to reduce the bandwidth needed by services when sending data. This improves the Quality of Experience (QoE) for the end user.
Compressing the size of data content, using techniques such as de-duplication, may significantly reduce the bandwidth required, and solutions to do this are commercially available.
The process of de-duplication is illustrated in FIG. 1, in which a compressor 1 or a de-compressor 2 identifies byte patterns in a payload of a data stream and associates an identified byte pattern with a shorter index, referred to as a signature. This is done for many byte patterns, leading to many signatures, which are stored in a database. The data payload and the associated signatures are transmitted to the remote side, where the same association is stored in a database. This phase is denoted as the learning phase. At some point in time the de-compressor 2 agrees with the compressor 1 to start sending compressed data over the link. Alternatively, a signature can be assigned to a pattern of bytes as soon as the pattern is repeated. Subsequent byte patterns identified by the compressor 1 are replaced with the corresponding signatures, which are sent over the link. At the de-compressor 2, the signatures are again replaced with the full byte patterns. The original data stream is thus recreated and further processed as normal. Solutions are implemented in the network user plane and do not rely on the control plane.
A compressor 1 typically associates the signatures with a de-compressor 2. The correct signatures may therefore rely on knowledge of the identity of the de-compressor 2 (or compressor 1). It is possible that a compressor 1 may associate a signature with a particular byte pattern for sending the data associated with the byte pattern to a particular de-compressor 2, and associate a different signature to the same byte pattern for sending the data associated with the byte pattern to a different de-compressor.
Content compression and de-duplication is available between a server and one or more mobile clients targeting the enterprise scenario. However, if the server side is integrated in a mobile network node below a mobility anchor point, for example in a Serving Gateway (SGW), Serving GPRS Support Node (SGSN) or Radio Network Controller (RNC), then the compression and de-compression must take into account mobility of the mobile terminal. The network side needs to be able to compress data so that any mobile terminal may de-compress it, and be able to de-compress data from any mobile terminal. In this case, a mobile terminal may roam into a new cell handled by a different de-compressor, but the network side compressor may not have the identity of the different de-compressor.
FIG. 2 illustrates a network architecture intended for an enterprise scenario in which an endpoint (such as a central office) 3 connects to one or more branch offices, or an office connects to a mobile workforce 4, 5, 6. In this case, the office 3 side uses compression on the downlink and decompression on the uplink, and the mobile workforce side uses de-compression on the downlink and compression on the uplink.
Existing solutions for mobile clients 4, 5, 6 in an enterprise scenario cannot be directly deployed for a public scenario in a mobile network infrastructure if the downlink compression/uplink de-compression is deployed in a network node below the mobility anchor point, such as a PDN Gateway (PGW) 7 (or a GGSN), as shown in FIG. 3. The reason that existing solutions cannot be deployed in this type of architecture is that the identity of the de-compressor may change dynamically owing to mobile terminal mobility. In this example, a terminal 4 is connected to a source eNodeB 8 and a source SGW 9 but, because of mobility of the terminal 4, may subsequently connect to a target eNodeB 10 and a target SGW 11. The compressor at the office side needs to know which signatures can be used when compressing data towards a certain de-compressor. For example, if a mobile terminal is connected to a source SGW 9 in a Long Term Evolution (LTE) network, the compressor at the terminal 4 knows the identity of the de-compressor associated with the source SGW, and so can send compressed data using signatures. If the mobile terminal subsequently moves and connects to a new target SGW 11, the compressor must communicate with a new de-compressor.
Existing solutions to account for mobile terminal mobility are based on the de-compressor sending a notification to the compressor that it has received an unknown signature in a session. This will happen after handover of the mobile terminal, when the new de-compressor has not established a signature database with the compressor. The compressor then resets compression for that session and recommences the learning phase again. However, this approach result in the compression being less efficient since the learning phase can take around 2 hours to reach a compression efficiency of 80%.
Some solutions also deploy a handshake procedure between compressor and de-compressor to certify that compression is supported at both ends. However, this solution will induce some delay and data payload may need to be sent uncompressed until the de-compressor is identified.